今天的文章是針對沒有技術背景的 PM，希望可以幫助你們，在遇到客戶詢問這類問題時，能更有自信及底氣的去做判斷。

身為 PM ，你是否有經歷過這種時刻？
會議室裡，你和業務同事正向客戶展示產品。突然，客戶的 IT 主管或技術人員眉頭一皺，問說：「聽起來不錯，但你們的系統能不能跟我們家現在使用的系統串接，還有能不能當業務把一個案子標示為成交時，就自動觸發合約發送？」

瞬間，你感覺自己肌肉緊繃、心跳加速，腦中飛快運轉：「好像可以... ...但不確定。要怎麼回答，才能顯得專業又不會變成亂開支票，到時候回去又被 RD 罵爆？」

想要有底氣的回答這類問題，除了需要熟悉自家產品外，你還需要讀懂產品的 API 文件 (API Documentation)。

你可能會說：「我也試過，可是一打開都是一堆英文和程式碼，根本看不懂啊 QQ」。
別怕，讓我們先從心態建立開始。身為 PM ，我們讀 API 文件，為的不是學會如何寫程式，而是要看懂系統有哪些功能，以及要順利得到結果，需要提供哪些資料。
所以到底該怎麼看？就讓我們繼續看下去。

PM 的 API 文件攻略

你們能做什麼？ —— 尋找 Endpoints

客戶問：「你們能自動發送合約嗎？能查簽署狀態嗎？能下載簽完的文件嗎？」

此時你可以打開 API 文件，找到左邊導覽列，尋找「Endpoints」、「Core Functions」或「API Reference」的章節。接著像看菜單一樣掃描列表，找到POST /tasks (建立任務)、GET /tasks/{id} (查詢任務狀態)、GET /documents/{id}/download (下載文件) 這種動詞+名詞的組合。
當然，假如你們公司的 API 文件上面都有清楚標示中文的話，就直接找對應的功能就可以了。

充滿自信的 PM 回答：只要看到這些關鍵字，就能回答客戶：「可以，這些都是我們系統的標準功能，只要你們的系統呼叫我們的 API 就可以執行。」

那我們需要提供什麼？ —— 查看 Parameters

客戶問：「好，那我要發送合約的話，要提供哪些資料給你們？」

點進剛剛找到的POST /tasks (建立任務)說明頁，找到一個叫做「Parameters」或「Request Body」的區塊，裡面會清楚列出所有所需的參數，例如"signer_id": "number" 、signer_name: string... …等等。

充滿自信的 PM 回答：你可以直接看著這個表，像顧問一樣告訴客戶：「我們須需要您提供簽署人的 ID、姓名。」通常對方技術人員不會繼續細問回傳格式，因為這部份他們會在拿到 API 文件後看的到，也會直接跟 RD 對接。(通常啦，但有經驗的 PM 就會知道，有些客戶連這個都會問你)

我們如何得知進度？ —— 尋找 Webhooks

客戶問：客戶簽完後，我們的系統要怎麼馬上知道，然後進行後續操作？

這個問題的關鍵字是「馬上知道」。這種像是訂閱通知的功能，通常在 API 文件中會獨立出一個叫 「Webhooks 」的章節。可以在裡面找找有沒有像是task.completed 或 document.signed 這樣的「事件 (Event)」。當然，每個系統的方式不同，有些系統是利用 API 來回傳簽署狀態的，這時候就可以回到問題一的步驟，去看看有沒有相關 API。

充滿自信的 PM 回答：如果有看到相關的東西，你就能自信的說：「沒問題，簽署完成的當下，我們系統會主動發送通知給您的系統，就不用您這邊一直來查詢狀態。」

從專案經理到解決方案顧問

一步步拆解開來看懂 API 文件後，是不是覺得它沒那麼可怕了？了解它，它就會是 PM 在技術溝通中的最佳盟友。
學會看 API 文件，能讓 PM：

• 對客戶：建立信任，設定正確的期望。
• 對內部工程師：提出更精準的需求，減少溝通成本。
• 對自己：從專案管理者進化到解決方案顧問的關鍵。

今天我們學會了如何看懂文件，不再怕技術問題答不出來，也更了解系統能做到什麼。明天，我們要用教育訓練的角度，去帶著客戶端的實際使用者來操作一次完整的簽署流程。